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(54) Method and apparatus for reducing premature termination of mobile station LCS procedure 
during RR operations 



(57) A method is disclosed for operating a mobile 
station in cooperation with a network operator, as is a 
system including the mobile station and the network op- 
erator. The method operates* upon an occurrence of a 
RR procedure, including HO and CRS, that affects the 
mobile station, to determine if a location procedure Is 
ongoing in the mobile station and, if it is, to complete the 
location pi'ocedure and. to report the measurement re- 
sults. (which may be a failure indication) in a message 
from the mobile station to a target radio network control- 
ler. The location procedure may be, for example, a LCS 
procedure executed during a Combined Hard Handover 
and SRNS Relocation procedure for a PS and CS do- 
main, and applies to both intra-SGSN SRNS relocation 
and-for inter-SGSN and SRNS relocation. The location 
procedure may also be, for example, a LCS procedure 



executed during a Combined Cell/URA/GRA Update 
and SRNS Relocation procedure for the PS domain, and 
also applies to both intra-SGSN SRNS relocation and 
for inter-SGSN SRNS relocation. When the location pro- 
cedure is a LCS procedure, the method further sends 
LCS parameters from a source RNC to the target RNC. 
The LCS parameters can be sent in a Source RNC to 
Target RNC Transparent Container in a Relocation Re- 
quired message, or in a Relocation Commit message, 
or in a Forward SRNS Context message. The measure- 
ment results message may be sent by the mobile station 
before or after sending a UTRAN Mobility Information 
Confirm message from the mobile station to the target 
RNC/BSC. 
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Description 
TECHNICAL FIELD: 

5 [0001] These teachings relate generally to wireless communications systems and. more speclficany, to procedures 
for detenmining a location or a position of a mobile station (MS) within the wireless network (NW). 

BACKGROUND: 
10 [0002] The following abbreviations are herewith defined. 



3G 

A/Gb mode 
BSC 
IS BTS 
CN 
CRS 
CS 
DL 

20 EDGE 

E-OTD 

GERAN 

GGSN 

GMLC 
25 GPS 

GRA 

GSM 

GTP 

HO 

30 IMSI ' 
IP 

lu mode 

lur 

lur-g 
35 LCS 
. ME 

MM 

MS 

MSG. 
40 NAS 

PDCP 

POP 

PDU 

PS. 

45 QoS 

RAB 

RAN 

RANAP 

RNC 
50 RNTI 

RR 

RRC 

RRLP 

SGSN 
55 SMLC 

SRNS 

UE . 

UL 



Third Generation (cellular system) 

Mode of operation of MS when connected to the core network via GERAN and the A and/or Gb interfaces 

Base Station Controller 

Base Transceiver Station 

Core Network 

Cell Re-Selection 

Circuit Switched 

Down Link (to the MS) 

Enhanced Data rate for Global Evolution 

Enhanced-Observed Time Difference 

GSM/EDGE Radio Access Network 

Gateway GPRS Support Node 

Gateway Mobile Location Center 

Global Positioning System 

GERAN Registration Areia 

Global System for Mobile Communications 

GPRS Tunneling Protocol 

Handover 

International Mobile Subscriber Identity 
Internet Protocol 

Mode of operation of MS when connected to the core network via GERAN or UTRAN and the lu interface 

A logical Interface between two RNC 

A logical interface between two BSCs 

Location Services 

Mobile Equipment 

Mobility Management 

Mobile Station 

Mobile Switching Center 

Non-Access Stratum 

Packet Data Convergence Protocol 

Packet Data Protocol 

Packet Data Unit 

Packet Switched 

Quality of Service 

Radio Access Bearer 

Radio Access Network 

Radio Access Network Application Part 

Radio Network Controller 

Radio Network Temporary Identity 

Radio Resources 

Radio Resource Control 

Radio Resource Location Procedure 

Serving GPRS Support Node 

Serving Mobile Location Center 

Serving RNS 

User Equipment 

Uplink (from the MS) 
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UMTS Universal Mobile Telecommunications System 

URA UTRAN Registration Area 

UTRAN Universal Terrestrial Radio Access Network 

VMSC Visited MSG 

[0003] Reference can also be made to 3GPP TR 21.905, V4.4.0 (2001-10). Third Generation Partnership Project; 
Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications (Release 4). 
[0004] Over the period of a decade the GSM standard has evolved from a basic voice service to a wide variety of 
speech and data services. In the 3GPP Release 5 the functional split between the GSM/EDGE Radio Access Network 

10 (GERAN) and the core network (CN) will be aligned with the functional split between UTRAN and the CN, thereby 
enabling GERAN to connect to the same 3G core network and to provide the same set of services as UTRAN. This 
functionality split implies a new architecture for GERAN and significant modifications to the GERAN radio protocols. 
' [0005] Several new; interfaces such as lu and lur-g are defined for the GERAN architecture. The lu interface is com- 
mon between UTRAN and GERAN. An lu-ps and lu-cs interface is being considered, where lu-ps is the interface 

15 targeted for the packet switched (PS) domain, and lu-cs is the Interface targeted towards the circuit switched (CS) 
domain. Both of these Interfaces will be supported by the GERAN specifications.. The lur-g. is the interface between 
two GERANs, and supports signaling information between them (note that the lur-g is currently planned to support 
only the control plane procedures of lur). 

[0006] A Mobile Station (MS) can be attached to the core network through either the lu-cs or lu-ps, or through both 
20 the lu-cs and lu-ps interfaces. The MS can also be attached to the CN through the legacy interfaces A and Gb. As a 

result, the GERAN Radio Resource Control (RRC) protocol is based on both the GSM Radio Resource (RR) and the 

UTRAN RRC specifications. The MS can operate in either the A/Gb mode or the lu mode. The A/Gb mode is defined . 

for the MS when connected to a GERAN with no lu interface towards the CN. The lu mode is defined for the MS when 

connected to a GERAN with lu Interfaces towards the CN. 
25 [0007] UMTS has a standardized relocation procedure that Is expected will' be used as well in the GERAN lu mode. 

Figs. 1 and 2 Illustrate the relocation procedure, and can be found as well in the standard 3G TS 23.060, V4.2.0 

(2001-1 0), Third Generation Partnership Project; Technical Specification Group Services and Systenh Aspects; General 

Packet Radio Service (GPRS); Service Description; Stage 2 (Release 4), More specifically. Fig. 2.shows the operation 
. of the currently specified Combined Hard Handover and SRNS Relocation procedure for the PS doniain. The Illustrated 
30 sequence is valid for both intra-SGSN SRNS relocation and for inter-SGSN and SRNS relocation. Fig. 3 shows the 

operation of a Combined Cell /URA Update and SRNS Relocation procedure for the PS domain. This sequence is valid .. 

for both intra-SGSN SRNS relocation and for Inter-SGSN SRNS relocation. The Cell Update and Relocation procedures 

have been accepted by standardization committees to be adopted from UTRAN to GERAN Ju mode. *. 

[0008] According to current GSM specifications (Release 1998 (R98) and Release 1999 (R99). GSM 03.71). the 
35 E-OTD and GPS MS positioning procedures are terminated in the case of handover, or upon the occurrence of some 

other RR management procedure. More specifically, what is currently specified is that: 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already 
in progress if inter-BSC or int^r-MSC handover is needed and is not precluded by the particular location procedure 
40 and its current state. 

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already 
in progress if an intra-BSC handover or other intra-BSC RR management procedure is needed and is not precluded 
by the particular location procedure and its current state. 
, 45 • . ' ' • : ■ - . • 

[0009] As may be appreciated, the current approach results in GPS and E-OTD positioning procedures being tenmi- . 
nated in many cases due to HO or some other RR procedure, requiring the VMSC (or the GMLC) to restart the MS 
positioning procedure. This results in additional.delays. as well as in an increased MS power consumption, and the in 
some cases the entire positioning operation may fail within the time specified by an application. 

50 

SUMMARY OF THE PREFERRED EMBODIMENTS 

[0010] The foregoing and other problems are overcome, and other advantages are realized, in accorjdance with the 
presently preferred embodiments of these teachings. 
55 [0011] These teachings pertain to Assisted GPS. E-OTD and other suitable location methods and systems and pro- 
vide a technique to avoid undesired termination of a LCS procedure due to some RR procedure (e.g.. HO or CRS). 
The LCS process and the supplying of its associated parameters are moved -when required from a current serving 
BSC/RNC/SMLC and MSC/SGSN to a new serving entity with a relocation procedure. These teachings are applicable, 
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for example, to GERAN lu mode standards as well as to UTRAN standards, and may be applied as well to the GERAN 
A/Gb mode, while possibly requiring a new interface between BSCs (comparable to the lur-g interface in the lu mode) 
when operating in the A/Gb mode. 

[0012] A method is disclosed for operating a mobile station in cooperation with a network operator, as is a system 
5 including the mobile station and the network operator. The method operates, upon an occurrence of a RR procedure, 
including HO and CRS, that affects the mobile station, to determine if a location procedure is ongoing in the mobile 
station and, if it is, to complete the location procedure and to report the measurement results (which may be a failure 
indication) in a message from the mobile station to a target radio network controller. The location procedure can be, 
in accordance with an embodiment of this invention, a LCS procedure that is executed during a Combined Hard Hando- 
10 ver and SRNS Relocation procedure, for both the PS and CS domains, and applies to both intra-SGSN/MSC SRNS 
. relocation and inter-SGSN/MSC and SRNS relocation. The location procedure can also be, in accordance with another 
embodiment of this invention, a LCS procedure that is executed during a Combined Cell/URA Update and SRNS 
Relocation procedure for the PS domain, and also applies to both intra-SGSN SRNS relocation and for inter-SGSN 
SRNS relocation 

15 [0013] For the LCS procedure, the method further sends LCS parameters from a source RNC/BSC to the target 
RNC/BSC. The LCS parameters in this case are sent in a Source RNC to Target RNC Transparent Container in a 
Relocation Required message (note should be made that the name of this container Is UTRAN specific, and that it 
may be referred to differently in, for example, GERAN). LCS parameters may also be sent from the source BSC/RNC 
to the target BSC/RNC in a Relocation Commit (SRNS Contexts) message or, if no lur(-g) is available, in a Forward 

20 SRNS Context message. Note in this case that the reference to lur-g is GERAN specific, but should not be viewed as 
being a limitation upon the practice of this invention. 

[0014] The LCS parameters can include at least one of (I) a requested location accuracy; (ii) a requested location 
response time; (iii) details pertaining to a currently ongoing location process; and (iv) a GMLC address. 
[0015] The measurement results message may be sent by the mobile station before or after sending a GERAN/ 
25 UTRAN Mobility Information Confirm message from the mobile station to the target BSC/RNC. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] The foregoing and other aspects of these teachings are made more evident in the following Detailed Descrip- 
30 tlon of the Preferred Embodiments, when read In conjunction with the attached Drawing Figures, wherein: 

Fig. 1 is a block diagram of a wireless communications system that is suitable for practicing these teachings; 

Fig. 2 Illustrates the operation of a conventional Combined Hard Handover and SRNS Relocation procedure for 
35 the PS domain, where the illustrated sequence is valid for both intra-SGSN SRNS relocation and for Inter-SGSN 

and SRNS relocation; 

' t» 
Fig. 3 Illustrates the operation of a conventional Combined Cell/URA Update and SRNS Relocation procedure for 
the PS domain, where the illustrated sequence is valid for both intra-SGSN SRNS relocation and for Inter-SGSN 
40 SRNS relocation; 

Fig. 4 illustrates the operation of the relocation procedure with LCS data for the case of Cell Reselectlon (PS 
domain) in accordance with the teachings of this Invention; and 

45 Fig. 5 is a logic flow diagram that illustrates an LCS Relocation in an IP RAN architecture in accordance with a 

further aspect of these teachings. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

50 [0017] Referring first to Fig. 1 , there is Illustrated a simplified block diagram of an embodiment of a wireless com- 
munications system 5 that is suitable for practicing this invention. The wireless communications system 5 includes at 
least one mobile station (MS) 100, also referred to herein as User Equipment (UE). Fig.1 also shows an exemplary 
network operator having, for example, a Serving GPRS Support Node (SGSN) 30 for connecting to a telecommunica- 
tions network, such as a Public Packet Data Network or PDN, at least one base station controller (BSC) 40, and a 

55 plurality of base transceiver stations (BTS) 50 that transmit in a forward or downlink direction both physical and logical 
channels to the mobile station 100 in accordance with a predetermined air interface standard. A reverse or uplink 
communication path also exists from the mobile station 100 to the network operator, which conveys mobile originated 
^ access requests and traffic. 
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[0018] When the MS 100 moves from a cell served by a first BTS 50 to a cell served by another BTS 50, when both 
are controlled by the same BSC 40, an inter-BSC handover (HO) is executed. However, the MS 100 may also transition 
between cells served by BTSs 50 that are individually controlled by different BSCs 40, In this case the HO is considered 
. to be an intra-BSC HO. 

5 [0019] The air interface standard can conform to any suitable standard or protocol, and may enable both voice and 
data traffic, such as data traffic enabling Internet 70 access and web page downloads. In the presently preferred em- 
bodiment of this invention the air interface standard is a Time Division Multiplei^ccess(TDMA) air interface that supports 
a GSM or an advanced GSM protocol and air Interface, although these teachings are not intended to be limited to 
TDMA or to GSM or GSM-re'lated wireless 'systems. 

10 [0020] The network operator may also include a suitable type of Message Center (MC) 60 that receives and forwards 
messages for the mobile stations 100. Other types of messaging service may include Supplementary Data Services 
and one under currently development and known as Multimedia Messaging Service (MMS), wherein image messages, 
video messages, audio messages, text messages, executables and the like; and combinations thereof, can be trans- 
ferred between the network and the mobile station 100. 

15 [0021] The mobile station 100 typically includes a microcontrol unit (MCU) 120 having an output coupled to an input 
of a display 140 and ah input coupled to an output of a keyboard or keypad 160. The hriobile station 100 may be a 
handheld radiotelephone, such as a cellular telephone or a personal communicator The mobile station 100 could also 
be contained within a card or module that is connected during use to another device. For example, the mobile station 
10 could be contained within a PCMCIA or similar type of card or module that. is installed during use within a portable- 

20 data processor, such as a laptop or notebook computer, or even a computer that Is wearable by the user. 

[0022] The MCU 120 is assumed to include or be coupled to some type of a memory 130, including a read-only 
memory (ROM) for storing an operating program, as well as a random access memory (RAM) for temporarily storing 
required data, scratchpad memory, received packet data, packet data to be transmitted, and the like, A separate, 
^ removable SIM (not shown) can be provided as well, 4he SIM storing, for example, a preferred Public Land Mobile 

25 Network (PLMN) list and other subscriber-related information. The ROM is assumed, for the purposes of this invention, 
to store a program enabling the MCU 120 to execute the software routines, layers and protocols required to implement 
the improved MS LCS procedure h accordance with these teachings, as well as to provide a suitable user Interface 
(Ul), via display 140 and keypad 160, with a user. Although not shown, a microphone and speaker are typically provided 
for enabling the user to conduct voice calls in a conventional manner. 

30 |0023] The mobile station 100 also contains a wireless section that includes a digital signal processor (DSP) 180, 
or equivalent high speed processor or logic, as well as a wireless transceiver that includes a transmitter 200 and a 
receiver220, both of which are coupled to an antenna 240 for communication with the network operator. At least one 
local oscillator (LO) 260, such as a frequency synthesizer. Is provided for tuning the transceiver. Data, such as digitized 
voice and packet data, is transmitted and received through the antenna 240. 

35 [0024] It has been realized that the termination of the positioning procedure is In most cases unnecessary, but may 
be required, as the MS 100 is expected to behave In the same manner for both intra-BSC and inter-BSC HOs, i.e., the 
MS 100 does not typically know a pnon when the BSC 40 will be changed during the HO procedure. In all cases in the 
following Table the positioning procedure is terminated according to current specifications. In the Table are also listed 
what kind of effects the HO or other RR procedure has on the LCS, and what is required to be done in order to continue 

40 the LCS procedure. 
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10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



Positioning 
method 



(Assisted) GPS 



E-OTD 



RR Procedure 



Effect on positioning 
measurement process 



Inter MSC/SGSN handover/ | None*# 
CRS 



Inter BSC handover/CRS 
(Intra MSG or SGSN) 



Intra BSC handover/CRS 

Other RR management 
procedure (=lntra Cell 
procedure) 



Inter MSC/SGSN handover/ 
CRS 



Other RR management 
procedure (=lntra Cell 
procedure) 



Actions required to 
continue positioning 
procedure 



New serving BSC/SMLC and 
MSC/SGSN needs to be 
informed about the ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
previous SMLC and MSC/ 
SGSN), 



New serving BSC/SMLC 
needs to be informed about 
the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to old SMLC). 



Nothing 



None 



Nothing 



Inter BSC handover/CRS 
(Intra MSC or SGSN) 



Intra BSC handover/CR,S 



Assistance data delivered to 
MS is not valid anymore. But 
there is possibility that the 
MS has already managed to 
make the majority of the 
measurements, or MS can 
internally convert the 
assistance data to new 
serving BTS, and the 
amount of new neighbor 
BTSs is small, in these 
cases it would be still 
possible to continue the 
measurement procedure in 
MS under the new serving 
BTS. # 

None 



New serving BSC/SMLC and 
MSC/SGSN needs to be 
informed about this ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
old SMLC and MSC/SGSN), 



New serving BSC/SMLC 
needs to be informed about 
the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to the previous 
SMLC). 



Nothing 
Nothing 



*Note: this assumes thai either GSM to GPS «me relation Is not included to the assistance data, or the MS manages to utilize the GSM to GPS time 
relation in the previous cell before the occurrence of the HO. 

#Note: The s Jndard should a„ow the MS ,o send either the measure^nt response (with valid .measurement data), or an error ,nd.caUon (.n case 
the MS cannot perform satisfactory measurements under the new serving BTSs). 

[0025] In order to avoid termination of an ongoing LOS procedure due to an occurrence °f P;";^^^^^^; 
g. HO or CRS), the LCS process (with the required parameters) is preferably continued from '^'^ 
RNC/SMLC and MSC(server)/SGSN to the new serving entities with a relocation procedure. It is noted that or the 
caseX^-BSC procedures this is not required, but the termination of the LCS procedure "f^^^^jf « 
and R99 as the MS 100 was required to behave in some predictable manner irrespective of whether there is an in- 
ter-BSC/CRS or intra-BSC handover/CRS. . . . ^.^ -^„e. „,h-r rr 

10026] It is preferred that the positioning procedure never be terminated in the case °f HO CRS °r °t^^^^^^^^ 
procedure if the measurement command has been delivered successfully to the MS 100. If the HO or CRS shou d 
TcTr during the transfer of a measurement command (or assistance data) to the MS 100 the positioning procedure 
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* ■ ■ ■ 

may be terminated, or it may be continued, possibly at the choice of the netw.orl< operator. 

* * * • • 

Relocation Procedure with LCS Data 

5 [0027]- Fig. 4 provides an example of the relocation procedure with LCS data for the case'bf the Cell Reselection 
(PS domain) in accordance with an aspect of this invention. Fig. 4 maybe contrasted with the conventional procedure 
depicted in Fig. 3. In Fig. 4. the MS 100 can be seen to perform a cell update in the new cell first, and after that to send 
a response to the GPS/E-OTD measurement command (see Step 12X). Other improvements and modifications to the 
conventional Cell Reselection (PS domain) procedure are made apparent in the ensuing description of Fig. 4. Note 

10 should be made, however, that these teachings are not limited for use only with the illustrated Combined CeWIURAJ 
GRA Update and SRNS Relocation procedure for the PS domain procedure, but can be applied as well, by example, 
to the Combined Hard Handover and SRNS Relocation procedure for the PS domiain shown in Fig. 2, and also to the 
Combined Hard Handover and SRNS Relocation procedure for the CS domain. These teachings apply as well.to LCS 
Reselection in an IP RAN architecture, as will be discussed below. 

15 [0028] Referring now to the enumerated process steps shown in Fig. 4, a description of each step is now provided. 

1) After having made cell re-selection, the MS 100 sends a Cell Update/URA/GRA Update message to the UTRAN 
or, in accordance with an aspect of these teachings, to the GERAN. Upon reception of the message, the target 
RNC/BSC forwards the received message towards the source SRNC via lur (note that in the following signal flow 

20 description a reference to RNC denotes as well the BSC for the GERAN case). The source SRNC then decides 

to perform a Combined Cell/URA/GRA Update and SRNS Relocation towards the tai^et RNC. 

2) The source SRNC initiates the relocation preparation procedure by sending a Relocation Required message 
(Relocation Type, Cause, Source ID, Target ID, Source RNC to Target RNC Transparent .Container) to the old 

25 (previous) SGSN. The source SRNC sets the Relocation Type to "UE not involved".' The Source RNC to Target 

RNC Transparent Container includes the necessary information for Relocation co-ordination, security functionality, 
and RRC protocol context Information (including UE Capabilities). . , ; 

In accordance with an aspect of this invention, the LCS parameters (e.g., requested LCS QoS, what positioning 
procedure is active, details of the currently ongoing location process, GMLC Address of the active positioning 

30 procedure) may be included in the Relocation Required niessage in the Source RNC to Target RNC Transparent 

Container. Note in this reigard that the LCS QoS includes, for example, the required location accuracy and the 
response time. Another, less preferred technique is described below with respect to Step 7. 

3) The old SGSN determines from the Target ID if the SRNS Relocation is an intra-SGSN SRNS relocation or an 
35 Inter-SGSN SRNS relocation. In case of Inter-SGSN SRNS relocation the old SGSN initiates the relocation re- 
source allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Signalling, 
MM Context, PDP Context. Target Identification. UTRAN Transparent Container^ RANAP Cause) message to the 
new SGSN. At the same time a timer is started on the MM and PDP contexts in the old SGSN, as specified in the 
Routeing Area Update procedure in the subclause Location Management Procedures (UMTS Only) found in 3G 

40 TS 23.060. The Fonward Relocation Request message Is applicable only in the case of the Inter-SGSN SRNS 

relocation. 

4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indi- 
cator, Source RNC to Target RNC: Transparent Container. RABs To Be Setup) to the target RNC. For each RAB 

45 requested to be established. RABs To Be Setup contain Information such as RAB ID, RAB parameters, transport 

Layer Address and lu Transport Association. The RAB ID information element contains the NSAPI value, and the 
RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address 
for user data, and the.lu Transport Association corresponds to Tunnel Endpoint Identifier Data. 

After all necessary resources for accepted RABs, including the Ju user plane, are successfully allocated, the 
50 target RNC sends the Relocation Request Acknowledge (RABs setup, RABs failed to setup) mesisage to the new 

SGSN. The target RNC. for each RAB to be setup (defined by an IP Address and a Tunnel Endpoint Identifier), 
receives both forwarded downstream PDUs from the source SRNC as well'as downstream PDUs from the new 
SGSN. ' ' / 

5)When resources for the transmission of user data between the target RNC and the new SGSN have been 
55 allocated, and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause. 

' RANAP Cause, and Target RNC Information) Is sent from new SGSN to old SGSN. This message indicates that 
the target RNC is ready to receive frpm the source SRNC the downstream packets not yet acknowledged by the 
MS 100. i.e., the relocation resource allocation procedure is terminated successfully. RANAP Cause is information 
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from the target RNC to be forwarded to the source RNC. The RAB Setup Information, one information element for 
each RAB, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from the source 
SRNC to target RNC. If the target RNC or the new SGSN failed to allocate resources the RAB Setup Information 
element contains only the NSAPI indicating that the source RNC Is to release the resources associated with the 
5 NSAPI, The Forward Relocation Response message is applicable only in the case of inter-SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs to be released, and 
RABs subject to data forwarding) message to the source SRNC. The old SGSN determines the RABs subject to 
data forwarding based on QoS. and those RABs are contained in RABs subject to data forwarding. For each RAB 

10 subject to data forwarding, the Information element is specified to contain the RAB ID, Transport Layer Address 

and lu Transport Association. The Transport Layer Address and lu Transport Association Is used for forwardinjg 
of DL N-PDU from the source RNC to the target RNC. 

7) Upon reception of the Relocation Command message from the PS domain, the source RNC starts a data- 
15 forwarding timer. When the relocation preparation procedure is terminated successfully, and when the source 

■ SRNC is ready, the source SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit 
(SRNS Contexts) message to the target RNC. The purpose of this procedure is to transfer SRNS contexts from 
the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence 
numbers of the GTP-PDUs next to be transmitted in the uplink and downlink directions, and the next PDCP se- 
20 quence numbers that would have been used to send and receive data from the MS 100. For connections using 

the RLC unacknowledged mode the PDCP sequence number is not used. 

In accordance with these teachings, and as was discussed above in Step 2, the LCS parameters may be 
included in the Relocation Commit message, although this technique is not presently more prefeaed than including 
the LCS parameters in the Relocation Required message in the Source RNC to Target RNC Transparent Container. 

25 

8) After having sent the Relocation Commit message, the source SRNC begins the fonwarding of data for the RABs 
subject to data forwarding. The data forwarding at SRNS relocation is carried out through the lu interface, meaning 
that the data exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and 
are routed at the IP layer towards the target RNC. 

30 

9) The target RNC sends a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For the SRNS relocation type UE Not Involved, the relocation execution trigger is the reception of the 
Relocation Commit message from the lur interface. When the Relocation Detect message is sent, the target RNC 
starts SRNC operation. 

35 

10) After having sent the Relocation Detect message, the target SRNC responds to the MS 100 by sending a Cell 
Update Confirm/URA/GRA Update Confirm message. Both messages contain UE information elements and CN 
Information elements. The UE information elements include among other information the new SRNC identity and 
S-RNTI. The CN information elements contain among other information the Location Area Identification and Rout- 

40 Ing Area Identification. This procedure is co-ordinated in all lu signalling connections existing for the MS. 

11) Upon reception of the Relocation Detect message, the CN may switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocaUon, the new SGSN sends Update PDP 
Context Request messages (new SGSN Address, SGSN Tunnel Endpoint identifier, QoS Negotiated) to the 

45 GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP. Context Response 

(GGSN Tunnel Endpoint Identifier) message. 

12) When the MS 100 has reconfigured itself, it sends the RNTI Reallocation Complete message to the target 
SRNC. 

50 

12X) In accordance with these teachings, if some positioning procedure was ongoing in the MS 100, the MS 100 
sends the response message including successful measurement reports or a failure indication. The message may 
be sent before of after sending the RNTI Reallocation Complete message. In this manner the ongoing MS 100 
positioning procedure is not required to be terminated, thereby overcoming the problems that were discussed 
55 above. The measurement results message may be sent by the mobile station before or after sending a GERAN/ 

UTRAN Mobility Information Confirm message from the mobile station to the target BSC/RNC. 

13) When the target SRNC receives the RNTI Reallocation Complete message, i.e.. the new SRNC-ID + S-RNTI 
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are successfully exchanged with the UE by the radio protocols, the target SRNC initiates the Relocation Complete 
procedure by sending the Relocation Connplete message to the new SGSN. The purpose of the Relocation Com- 
plete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN. If the 
user plane has not been switched at Relocation Detect, the CN upon reception of Relocation Complete switches 
5 the user plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, 

the hew SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

14) Upon receiving the Relocation Complete message, or if it is an inter-SGSN SRNS relocation; the Forward 
10 Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. When 

the RNC data-forwarding timer started in Step 7 expires the source RNC responds with an lu Release Complete. 

15) After the MS 100 has finished the Cell/URA/GRA update and RNTI reallocation procedure, and if :the new 
Routing Area Identification is different from the old, the MS 100 initiates the Routing Area Update procedure. See 

15 in the regard the subclause Location Management Procedures (UMTS Only). Note that it is only a subset of the 

RA update procedure that is performed, since the MS 100 is in the PMM-CONNECTED state. 

L CS Relocation in IP RAN Architecture . 

* ^ ^ * 

20 [0029] A discussion is now made of the positioning signaling flow in . a particular IP RAN architecture. Reference can 
also be made to Fig; 5 for a discussion of the positioning signaling flow. 

[0030] It should be noted, however, that this procedure need not be IP RAN specific, and could be employed as a 
normal positioning procedure in UTRAN.(or GERAN) by replacing references to Radio Network Access Server (RNAS) 
with RNC; It should be noted that the RNAS functionality can be Integrated into the BTS functionality. 

-25 . ^ ■ . - ■ \ ' 

1) The SGSN/MSC server sends a Location Request to the RNAS, 

2) The RNAS knows in yvhich cell the MS 1 00 is located, or pages the MS 1 00 to determine the current cell where 
the MS 100 is located. If the Location Request only requires the service area id the RNAS may send this directly 

30 to the SGSN/MSC server without involving the SMLC. 

3) The RNAS sends a Location Request to the SMLC. The SMLC determines if the cell accuracy (with possible 
other available infprmation, such as the current Timing Advance value and the received signal level) is sufficient, 
and then translates the cell id (and possibly the other avaiable information) into MS 100 location coordinates. 

35 Ifbetter accuracy is required, the SMLC requests the RNAS to obtain measurement results of the target MS 100. 

4) The RNAS sends a measurement request to the target MS 100. 

5) The target MS 100 sends the measurement results to the RNAS.. 

40 . 

6) The RNAS sends the measurement results to SMLC. 

7) The SMLC requests measurement results from the LMU (or the LMU reports periodically to the SMLC, in which 
case this step and the next step (8) can be omitted). 

45 \ 

8) The LMU sends the measurement results to the SMLC 

9) The SMLC calculates the location of the target MS 100. 

50 10) The SMLC sends the location calculation results to the RNAS. 

11) The RNAS sends the location result to the SGSN/MSC server. 

[0031] The IP RAN Architecture has some effect on the LCS relocation procedure in the HO/CRS case. In the IP 
55 RAN architecture the SMLC and possibly the RNAS may be maintained the same during the positioning procedure 
regardless of the HO or CRS (i.e.. the occurrence of the HO or CRS does not require a change in the RNAS or the 
SMLC). This means that in the IP RAN architecture the relocation procedure with the transfer of the LCS parameters 
is not required, if the RNAS is not changed." In the case where the RNAS is changed, the SMLC would still be the same, 
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and in this case the new RNAS is required to find the SMLC. This can be accomplished if during the relocation procedure 
the address of the SMLC is transported from the old RNAS to the new RNAS. 

[0032] It should be noted that absent the use of this invention the MS 1 00 will always abort the positioning procedure 
in the case of HO or CRS. This applies as well to the IP RAN architecture discussed above. 

[0033] It should be appreciated that the improved LCS procedure in accordance with these teachings does not pre- 
maturely terminate as often as in the prior art due to an occurrence of some HO, CRS, or other RR procedure, and 
thereby provides reduced average delays, lower power consumption in the MS 100, and improved service to the end 
user. 

[0034] While described in the context of presently preferred and exemplary embodiments of these teachings, those 
skilled in the art will recognize that changes in form and details may be made, and that these changes will still fall within 
the scope of these teachings. 



Claims 

1. A method for operating a mobile station in cooperation with a network operator, comprising: 

upon an occurrence of a RR procedure, including HO and CRS, that affects the mobile station, determining if 
a location procedure is ongoing in the mobile station; and 

if it is. completing the location procedure and reporting measurement results in a message from the mobile 
station to a target radio network controller. 

2. A nriethod as in claim 1 , wherein the location procedure is executed during a Combined Hard Handover and SRNS 
Relocation procedure for at least one of a PS or a CS domain, and applies to both intra-SGSN/MSC SRNS relo- 
cation and inter-SGSN/MSC and SRNS relocation. 

3. A method as in claim 1, wherein the location procedure is executed during a Combined Cell/URA/GRA Update 
and SRNS Relocation procedure for a PS domain, and applies to both intra-SGSN SRNS relocation and for in- 
ter-SGSN SRNS relocation 

4. A method as in claim 1 , further comprising sending LCS parameters from a source RNC/BSC to a target RNC/BSC. 

5. A method as in claim 4. wherein the LCS parameters are sent In a transparent manner. 

6. A method as in claim 4, wherein for a UTRAN case the LCS parameters are sent in a Source RNC to Target RNC 
Transparent Container in a Relocation Required message. 

7. A method as In claim 1. further comprising sending LCS parameters from a source RNC/BSC to a target RNC/ 
BSC in a Relocation Commit message. 

8. A method as in claim 1 , further comprising sending LCS parameters to the target RNC In a Forward SRNS Context 
message. 

9. A method as in claim 5, where the LCS parameters comprise at least one of: 

a requested location accuracy; 

a requested location response time; 

details pertaining to a currently, ongoing location process; and 
a GMLC address. 

10. A method as in claim 6, where the LCS parameters comprise at least one of: 

a requested location accuracy; 
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' ' ' ■ * . 

a requested location response time; 

details pertaining to a currently, ongoing, location process; and 

a GMLC address. 
■ 

11. A nriethod as in claim 7, where the LCS pararneters comprise at least one of: 

a requested location accuracy; ' ' 

■ • 

a requested location response time; 
' details pertaining to a currently ongoing location process; and 
a GMLC address. 

12. A method as in claim 8, where the LCS parameters comprise at least one of: ♦ * . 

a requested location accuracy; 

a requested location response time; 

details pertaining to a currently ongoing location process; and 
a GMLC address. 

13. A method as In claim- 1 . wherein the niessage is sent before sending a UTRAN Mobility Information Confirm mes- 
. sage froni the mobile station to the target RNC/BSC. 

14. A method as in claim i , yyherein the message is sent after sending a UTRAN Mobility Information Confirm mesaage 
from the mobile station to the target RNC/BSC. 

15. A wireless communications system having at least one mobile station for communicating with a network operator, 
comprising a controller in said mobile station, responsive to an occurrence of a RR procedure, including HO and ' 

. CRS, that affects the mobile station, for determining If a. location procedure is ongoing In the mobile station and, 
' if it is, for completing the location procedure and for reporting measurement results In a message transmitted from 
the mobile station to a target radio network controller. 

16. A system as in claim 1 5, wherein the location procedure is executed during a Combined Hard Handover and SRNS 
Relocation procedure for at least one of a PS or a CS domain, and applies to both intra-SGSN/MSC SRNS relo- 
cation and inter-SGSN/MSC and SRNS relocation. . 

17. A system as in claim 15, wherein the location procedure is executed during a Combined Cell/URA/GRA Update 
and SRNS Relocation procedure for a PS domain, and applies to both intra-SGSN SRNS relocation and for in- 
ter-SGSN SRNS relocation 

18. A system as in claim 15, where the system sends LCS parameters from a source RNC/BSC. to a target RNC/BSC. 

■ 

19. A systenri as in claim 18, wherein the system sends LCS parameters In a transparent manner. 

20. A system as in claim 1 8, wherein for a UTRAN case the system sends LCS parameters in a Source RNC to Target 
• RNC Transparent Container in a Relocation Required message. 

* * " * 

21. A system as in claim 15, where the system sends LCS parameters from a source RNC/BSC to a target RNC/BSC 
in a Relocation Commit message. 

22. A system as in claim 15. where LCS parameters are sent to a target RNC/BSC in a Forward SRNS Context mes- 
sage.. 
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23. A system as In claim 19, where this LCS parameters comprise at least one of: 

a requested location accuracy; 

a requested location response time; 

details pertaining to a currently ongoing location process; and 
a GMLC address. 

24. A system as in claim 20, where the LCS parameters comprise at least one of: 

a requested location accuracy; 

a requested location response time; 

details pertaining to a currently ongoing location process; and 
a GMLC address. 

25. A system as In claim 21 . where the LCS parameters comprise at least one of: 

a requested .location accuriacy; 

a requested location response time; 

details pertaining to a currently ongoing location process; and 
a GMLC address. 

26. A system as in claim 22, where the LCS parameters comprise at least one of: 

a requested location accuracy; ^ 
a requested location response time; 

details pertaining to a currently ongoing location process; and 
a GMLC address. 

27. A system as in claim 15, where the message is transmitted before transmitting a UTRAN Mobility Information 
Confirm message from the mobile station to the target RNC/BSC. 

28. A system as in claim 15, where the message is transmitted after transmitting a UTRAN Mobility Information Confirm 
message from the mobile station to the target RNC/BSC. 
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